Subject: Re: Adaptive pacing examples

From: [email-masked]
Date: Wed, 23 Feb 94 12:58:13 EST

Gnanaprakasam,
Thanks for the questions and expanded flows.  My responses are
imbedded below.
Peter

>
> >
> > To respond quickly to congestion, the pacing receiver may send an unsoli-
> > cited "reset window" indication to the pacing sender.  This indication may
> > be sent only as an IPM (not piggy-backed), with PRSP=0 and RWI=1.  Upon
>
> QUESTION I
> =========
>
> Why not just keep PRSP = 1 for RWI,
> like the way it is done for IWI and HWI.
> Although, the intention is to convey the unsolicited nature of this
> message, it kind of confuses the direction sense.
>

The reason for PRSP=0 was as you state, that I wanted PRSP to denote
a response to PREQ.  In other words, I meant it to distinguish
solicited from unsolicited responses and not as a direction indicator.
I envisioned the sender's code having to check for PRSP in the I and
UI frame cases, but needing another case for IPMs anyway.  So I don't
think it matters much what we set PRSP to.  Perhaps to be consistent
with my definition we should set it iff PRSP is owed at the time the
receiver sends RWI.

>
> QUESTION II
> ===========
>
> > PC=NWS is the condition that trigger PREQ
>
> I agree that this works as a good condition for most part.
> Do the implementors have the freedom to make the decision on
> when to ask for the next window size?
>
> If the data rate is low,
> I would probably ask for the next window when I am just about running
> out of current window rather than the above condition to put less
> burden on the receiver.
> (Example : Interactive traffic ; req/resp based protocol)
>
> If the data rate is higher one could ask for more window size
> just when you are at the beginning of the current window.
> (Example : File transfers with large SNA packet sizes over an IP tunnel with
> small path discovery MTU; every SNA packet needs atleast so many IP buffers. )
>
> Ideally should n't this be based on the rate of flow?

I left the "PREQ on first frame in window" rule intact in the revised
proposal because that's the conclusion Shannon guided the discussion
to at the AIW.  As I mentioned in Note 5 of the revision, the only
reason I can think of to change this rule is the one you suggest,  i.e.,
it could provide a means for sender to give the receiver feedback
on the usage of the current window.  I think Paul Brittain suggested
this general idea also at the AIW (sorry Paul if I am remembering this
wrong).

I think we need a specific proposal to consider.  Since Paul Wood's
proposal in a couple of weeks will be on a different tack, perhaps
you would like to flesh out this particular idea.  Here are some
questions to be answered:
  - Exactly how should the receiver interpret the PREQ position in
    the window to represent requests for a bigger/smaller/same
    next window?  Is PREQ in the (first frame, first & second frame,
    first n% of the window) a request for a larger window?  What
    about when the window size is 1;  is PREQ always a request for
    a larger window?
  - Will there be an interpretation for a smaller window request?
    Do we need a DWI (decrement window indicator) bit to respond with?
  - How is a sender to predict traffic which hasn't arrived yet when
    deciding to delay PREQ within the current window?  How can we
    ensure the scheme will not be wildly suboptimal, frequently
    introducing extra delay waiting for a pacing response?
  - Can you give an example of how you envision a sender determining
    what traffic types it is carrying (e.g., interactive versus file
    transfer).  Are you thinking of instantaneous queue depths or
    some sort of timer-based averaging measurement?  (I'm not asking
    for product plans, I just want to get a sense of how quickly
    you expect pacing to react to the sort of sensing you propose).

In all this discussion, we should remember that the RIG accepted
adaptive pacing as the ONLY mechanism because the sender's role was
simple and the receiver was not obliged to really make the adaptive
part work.  So whatever we propose to add to the sender's logic must
be relatively simple.

>
> Also, if vendors implement  real buffer
> reservation schemes and use the above condition to trigger
> it wastes a lot of buffers at the receiver's side when they
> choose a large initial current window size.
>

It's a tradeoff of larger outstanding windows versus the risk that
the sender would have to stop sending frequently.  Ideally we will
get the adaptive scheme working well so initial window sizes can be
small (APPN session pacing starts with 1).